1. Field of the Invention
The present invention relates to computer and communications systems. In particular, the invention relates to technology for connecting external devices with a computer or communications system.
2. Description of the Related Art
Many computer or communications systems that perform peripheral input/output functions or other network data exchange functions rely on one or more function modules to interconnect the system with one or more external devices. A function module is an input/output block facilitating data communication between a device external to a computer or communications system and internal components located within that system. Examples of function modules include processor cores and interface cores. Examples of internal components include host components such as system memory and central processing units (CPUs). Examples of external devices include hard disk drives, printers, external modems, floppy disk drives, and CD-ROMs. Traditionally, the function modules and host components are located on a single circuit board or on a single integrated chip.
Function modules need to be interconnected to the internal components. This interconnection facilitates data information sharing among the various function modules. For example, a function module may receive data from an external device and transmit the data to the system memory (also known as xe2x80x9cwritingxe2x80x9d to the system memory). Alternatively, the function module may receive data from the system memory (also known as xe2x80x9creadingxe2x80x9d from the system
FIG. 1 is a block diagram illustrating a prior art system 100 wherein five function modules 101-109 are inter-connected via a local bus 120. In an exemplary case, function module 101 is an IEEE 1394-95 controller, function module 103 is a peripheral component interconnect (PCI) bridge, function module 105 is an ethernet controller (in accordance with IEEE 802.3 Standard), function module 107 is a universal serial bus (USB), and function module 109 is a high-speed integrated device electronics (IDE) controller. In addition, each function module is directly connected to an external device 151-159 (external to the integrated circuit where the function modules and the host components are located).
Local bus 120 is connected to a central arbitrator 122, which in turn is directly connected to a host component 130 (e.g., system memory or CPU). Arbitrator 122 controls the traffic on local bus 120. The traffic on local bus 120 represents data exchanged between host component 130 and function modules 101-109. Whenever a function module 101-109 needs to write to and/or read from host component 130, the function module needs an access to local bus 120. In order to gain access to local bus 120, the function module sends an access request to arbitrator 122. Depending on the current traffic on local bus 120, arbitrator 122 either grants or denies the request. If access is granted, the function module performs the data exchange for a pre-determined period of time or for a pre-defined number of bytes. After the data exchange is complete, the access to local bus 120 is relinquished. At this time, another function module (or the same function module) may request access to local bus 120, and the cycle is repeated all over again.
Each function module is directly connected to local bus 120 but only one function module can transmit or receive data via local bus 120 at a time. Arbitrator 122 can handle only one access request at a time. Arbitrator 122 relies on bus arbitration wherein all function modules are polled for outstanding requests and then an access is granted to only one function module based on a fixed priority basis. If local bus 120 is already in use by a first function module (i.e., conducting a data exchange) when a second function module requests access to the bus, arbitrator 122 places the request from the second function module on hold. Only after the first function module completes its access to local bus 120 (i.e., completes its data exchange) will arbitrator 122 grant the request from the second function module. As such, the second function module has to wait until the first function module has completed its data exchange. This wait period (i.e., latency) adds to the actual time taken to complete a data exchange by the second function module and adversely affects the performance of the computer or communications system.
Prior art system 100 also requires that function modules 101-109 have internal buffers (i.e., memory space) for temporarily storing data. If a function module receives data from an external device but cannot have immediate access to local bus 120, the function module must hold the data in its internal buffer until access to the bus is granted. Larger internal buffers are required to accommodate longer wait times. Internal buffers are expensive and the dollar cost increases with increased number/size of buffers.
Generally, in prior art system 100, local bus 120 is balanced to operate at maximum operating frequency. When new function modules are added to local bus 120 or any old function modules are removed from local bus 120, the prior art requires rebalancing to create maximum operating frequency. This rebalancing adds to the dollar cost. Alternatively, if the design or architecture of the local bus is upgraded or enhanced, the design of function modules accessing local bus 120 may need to be enhanced or replaced. This also adds to the dollar cost.
In the prior art system 100, each function module has a predefined throughput (i.e., maximum bandwidth). Thus, if a particular function module requires additional bandwidth on local bus 120 to complete a data exchange, the function module may not exceed its allocated maximum bandwidth even though additional bandwidth is available (not used by other functions). To complete the data exchange, the function module must request and wait for another access to local bus 120. This results in an inefficient use of the available bandwidth on local bus 120 and slows down the performance.
An improved method and apparatus for connecting various function modules located within a computer or communications system are proposed. In accordance with the principles of the present invention, a port manager controller (PMC) having a direct interface to each of the function modules and to a host component such as a system memory or a CPU is provided. The PMC replaces both the local bus and the arbitrator of prior art systems. All the requests by function modules to access the host component are first processed by the PMC. The PMC schedules the incoming requests in accordance with predefined parameters, such as priority, efficiency, and/or timing.
The PMC is capable of handling more than one request at a time. The PMC is also capable of dynamically adapting to load conditions and rearranging the incoming requests to efficiently utilize the available bandwidth. Thus, the PMC reduces latency and improves the performance of the computer or communications system. The PMC also eliminates the need for changes in bus architecture when new function modules are added or old function modules are removed and permits the reuse of old function modules. The PMC also reduces the need for internal buffers and thereby reduces manufacturing costs.
In one embodiment, the present invention is a port manager controller for controlling access to a host component by a plurality of function modules, wherein the PMC comprises (a) a host component port configured to be connected to the host component; and (b) at least two function module ports, each configured to be connected via a point-to-point connection to one of the function modules. The PMC is configured to (1) receive a first access request from a first function module at a first function module port of the PMC, and (2) schedule a first access session for data exchange between the first function module and the host component via the host component port and the first function module port.